Experimentelle Methoden zum Aufspüren von Einbrüchen

Die Analyse von Computereinbrüchen zählt nach wie vor zu den anstrengendsten Tätigkeiten, die ein Informatiker ausüben kann. Warum gibt es für dieses Problem keine automatische Unterstützung? Weil vorhandenen Werkzeuge auf einer ungeeigneten Methodik basieren. Die Analyse von Einbrüchen strebt danach, aus dem aktuellen Zustand des Systems zu rekonstruieren, wie es zum Einbruch kommen konnte. Dazu werden die vorhandenen Spuren analysiert und dann geschlossen, was in dem System passiert sein muss, damit diese Spuren entstehen konnten. Beispielsweise könnte eine Analyse des Linux Slapper-Wurms so aussehen: ” Angreifer mit der IP-Adresse 10.120.130.140 haben eine besonders präparierte HTTPS-Anfrage an unseren Web-Server geschickt, der einen fehlerhaft formatierten Client-Schlüssel enthielt. Das verursachte einen Pufferüberlauf und rief eine Shell auf. Diese Shell speicherte dann eine mit uuencode kodierte Kopie des Wurm-Quellcodes, dekodierte und kompilierte sie und startete das erzeugte Programm unter dem Namen .bugtraq. Sobald das Programm ablief, versuchte der Wurm, andere Rechner des Netzwerks zu kontaktieren.“ (Beispiel aus [4].) Soll nun ein Analyst diesen Vorfall untersuchen, und sieht er dabei nur den .bugtraq-Prozess, ist eine seiner ersten Aufgaben, die Prozesse zu isolieren, die an dem Angriff beteiligt sind, und zwar sowohl Prozesse, die noch ablaufen, als auch solche, die bereits terminiert sind. In diesem Beispiel sind das der Web-Server, die (terminierte) shell, die entsprechenden cat, uudecode, und CÜbersetzer-Aufrufe, und endlich der .bugtraq-Prozess. Die übliche Vorgehensweise ist, bei einer Verletzung der Sicherheitsrichtlinien zu beginnen (hier wäre das der nicht erwünschte .bugtraq-Prozess) und sich dann mit Hilfe von Log-Dateien und Toolkits wie The Coroner’s Toolkit rückwärts bis zur ursprünglichen Ursache zu bewegen (hier zu der fehlerhaft formatierten HTTPS-Anfrage). Dieses deduktive Verfahren hat aber gravierende Nachteile: